home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000321_KHOADLEY@ib.rl.ac.uk _Fri Nov 13 11:00:39 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <KHOADLEY@ib.rl.ac.uk>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA11459; Fri, 13 Nov 92 11:00:39 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA15858; Fri, 13 Nov 92 11:13:28 +0100
  6. Received: from CERNVM.cern.ch by CERNVM.CERN.CH (IBM VM SMTP V2R2)
  7.    with BSMTP id 4460; Fri, 13 Nov 92 11:13:41 SET
  8. Received: from UKACRL.BITNET by CERNVM.cern.ch (Mailer R2.08) with BSMTP id
  9.  1219; Fri, 13 Nov 92 11:13:41 SET
  10. Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 3430; Fri,
  11.  13 Nov 92 10:12:24 GMT
  12. Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 7759; Fri, 13
  13.  Nov 92 10:09:29 GMT
  14. Via:        UK.AC.RL.IB; 13 NOV 92 10:09:13 GMT
  15. Message-Id: <"13 Nov 92 09:42:56 GMT KHOADLEY"@UK.AC.RL.IB>
  16. Date:       Fri, 13 Nov 92 09:42:56 GMT
  17. From: "KHOADLEY" (KHOADLEY at UKACRL)        <KHOADLEY@ib.rl.ac.uk>
  18. To: www-talk@nxoc01.cern.ch
  19. Subject:    ISINDEX on documents
  20.  
  21.  
  22. Somewhat off the current thread, but anyway ...
  23.  
  24. There seems little reason to me for the ISINDEX tag. Searching consists of
  25. two components: the client constructing a list of queries designed to
  26. retrieve the relevant information, and the server receving and processing
  27. those queries. Once you start to consider a single user initiated search
  28. generated multiple queries there seems to be little point in tieing searches
  29. down to particular tagged documents.
  30. (of course once a search generates multiple queries it can receive multiple
  31. replies. AS these replies could come from different servers it becomes the
  32. responsibility of the client end to aggregate the replies into something
  33. useful to return to the user: a selection panel for instance).
  34.  
  35. I'd like to see the ISINDEX tag dropped: the client is free to construct
  36. whatever queries they wish, using the existing HTTP query mechanism.
  37.  
  38. Instead of the ISINDEX tag, I think we need an INPUT tag. ISINDEX is quite
  39. used for purposes other than searching, eg. for "smart" documents or
  40. to calculate square roots ! (an example familiar to those at the HEPix
  41. meeting ...). However using a tag that appears to have been intended for
  42. search purpose for something different is confusing to the end user: ie
  43. the page asks for the value you wish to square root, whilst the client
  44. prompts you for a string to search for ....
  45.  
  46. Perhaps the following could be useful:
  47.            <INPUT VAR=x>Please enter your name</INPUT>
  48.            <DONEINPUT>
  49. ie a series of input fields with associated labels, and a button to say
  50. you have finished and now send the query. This opens the possibility
  51. of forms based pages generating smart documents. How you send the input is
  52. a different matter; maybe:
  53.     http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz
  54.  
  55. Kevin Hoadley, Rutherford Appleton Lab, khoadley@ib.rl.ac.uk